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ABSTRACT 



A system architecture enables remote browsing and admin- 
istration of physical file directories resident on a server from 
a remote client browser. The architecture has a browser and 
a user interface (UI) resident at a client. From the UI, the 
remote administrator can specify a path of a physical file 
directory in a file system located at the server. The browser 
sends an HTTP request that includes (he path to the server. 
A server-side script receives the client request and invokes 
a file system object to enumerate the files and/or folders for 
the directory path specified in the client request. The server- 
side script then creates a client-side script, which when 
executed at the client will instantiate a custom client-side 
object to cache the directory data and to present thai data in 
a dialog UI. The server returns the client-side script and 
directory data to the client, wherein the script is subse- 
quently executed to instantiate a local object to cache the 
directory data. Using the client UI, the remote administrator 
can view the directory data, navigate the data, set properties 
for the listed files or folders, add or rearrange directories, 
delete or move files, or perform other general administration 
tasks. 

23 Claims, 5 Drawing Sheets 
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SERVER ADMINISTRATION TOOL USING Another problem that compounds the difficulty of remote 

REMOTE FILE BROWSER administration of the Internet is that many Web sites implc- 

TECHNICAL FIELD rnent firewall protection that blocks many types of inquiries 

. , from reaching the Web server. Typically, firewall software 

This invention relates to servers for computer network 5 om its Kn? ^ tQ tQ ^ Wcfa 

systems and to server administration tools. More ... . , , . . , ,,r7 . 

particularly, this invention relates to remote administration f dc hM ™& °* cr ^ T' 

of server file systems using remote HTTP-based browsers as ^ ab ° *> rcvcnts mach ^ Erom ^de the firewall from 

the administration access portal for browsing and configur- ^mmunicating with, or seeing, the chent browser, 

ing directories in the file systems. ^ makmg ^ authentication very difficult. While conven- 

io tional administrative tools support remote administration 

BACKGROUND OF THE INVENTION ovcr locaJ nctwork5 , lhc y do not solve the problem of 

Acomputcr network system has one or more host network browsing directories over an HTTP firewall/proxy server, 

servers connected to serve data to one or more client Another concern is security. Allowing access to a Web 

computers over a network. Clients send requests for data site ' s files ^ configuration parameters may be dangerous 

and/or services to the servers over the network. The servers 15 m me absence of high security and authentication proce- 

process the requests and return responses to the clients back dures 

over the network. . . iL , c , . . 

« i . . „ Accordingly, there remains a need for a remote adminis- 

In the Internet setting, the clients typically execute a t . . , .J . . . r > 

. , t . . . J u , tration tool that enables remote management of a server s 

browser program that submits requests using conventional ,. L i . _ .i_ ? c « j ■ 

HTTP (Hypertext Transfer Protocol) request commands. ^ file ***** over ^ lnteraet - lhrou 6 h 4 fircwaU " and 10 a 

Each Internet server runs a Web server software program secure manner. 

that accepts HTTP requests and returns data in the form of SUMMARY OF THE INVENTION 
Web pages or documents. The Web pages arc commonly n . . t . , 
written in HTML (hypertext markup language) or XML ™* mvcnUon «»«™ a »)» tem ^hitecture that enables 
(extensible markup language) and may include text, images, „ rcmotc browsing and administration of physical file dim- 
sound, video, active code, and so forth. The server transmits 25 «™ resid t Dt 00 a server ? om a remot j chent b [ 0WSer ™5 
the Web pages back to the requesting client using standard s ^ m J?*!?* 1 * ^P 10 ^, standard netw ? r \ protoco1 ' 
HTTP response commands. The client browser renders the such as ^ to eDable i mplementation on th e Internet. 
Web page into human-perceptible forms. T£e«wcmierture!has!a?Drow^^ 

The Web pages and other program files, such as Active 30 * f lie j nt j The j UI n »B h _ t bc f lored loc ^ *\ ihc 

Server Pages (ASP) applications or custom programs, arc cheffifc?downloaded 00 demand from the server. The client 

stored and organized at the server in directories. Each Web UI Pf* nts filcs . {old ^ and ' or directory trees that are 

site consists of one or more directories that contain the owhcg locally at the chent to a remote administrator. The 

content files (typically the home page, images, etc) and administrator can navigate the files and/or folders of the 

programs. In general, a site administrator can define two 35 ™neffi» cached ^tory path using file browsing tools, 

different types of directories: physical directories and virtual ™e rerafcte administrator can ^select a file or folder, or 

directories. A physical directory is subdirectory of the Web s P=^g new path of a physical file directory located at the 
site's specified, or home, directory. A virtual directory is any l £ . a ^ iy 

directory not contained within the home directory. Virtual When the administrator designates a new path that is not 

directories are typically used to specify different URLs 40 cached at the client, the browser sends a client request that 

(Uniform Resource Locators) for different parts of the Web includes the new path to the server. The request conforms 

s i tc with standard HTTP. In this manner, the file browsing 

Site administrators have traditionally used local server- re q uesl * protected within an authenticated communication 

based administrative tools to browse and configure the files P*th (i.e, one that has already been secured) and is granted 

and directories. The administrators are typically present at 45 P^ sa g e lhr0U S h an y firewa11 mat raav exisl between lhe 

the server and can easily browse and configure the directo- client and server 

ries using a familiar user interface. Many administrative ThcjscrVctfrccwvcsTtrw^^ 

tools that are available today also support remote adminis- system ^fiject used to interface the file system. The file 

tration that allows an administrator to browse and lo con- systemfobjept enumerates the files and/or folders for the 

figure directories on the server from a remote computer on 50 directoryypath specified in the client request, 

the network, rather than from the server itself. The sc&er then creates executable code that will be run at 

Web site administrators would like to be able to configure the clientRo cache and present the directory data obtained by 

the site directories from a remote client over the Internet. the file sj&tem object. In one implementation, a server-side 

However, remote administration over the Internet raises a saipt CTc&tes a clieot^siri^ciiptn^ 

host of problems. One problem concerns the inability to 55 cUcn^sid^gbjc^rtOiXaJ^ i lh&i««uui m^l» Juvaui.y<dafaiand»to 

browser the server's physical files and directories from a t Mcscnt«tbaWdata,in«a^ ialog Ul. Absent this process, the 

remote computer over the Internet. There is no reliable client-sidj browser would not know what files, folders, 

means of determining what physical files and directories are and/or directories it will cache in order to present them in 

located on the Web server. A remote administrator can enter response^ the specified path query. The server thus prc- 

a virtual path name, such as a URL like 60 pares a client-side script that will bc able to cache the 

"www.microsoft.com\applications", but the administrator information for the client and downloads that script to the 

has no ability to browse the physical directories on the Web -KdieiitifQi&xccutiqn. 

server file system, such as documents listed in the physical The server returns the client-side executable and the 

directory "C:\". To view specific physical directories and set directory data to the client. The client subsequently executes 

valid configuration parameters, a remote administrator must 65 the script to instantiate a local object for {Circhjrjggtiis 

know the entire path and exact name of the file on the server ^kectoryidata The data is presented in the UI, which enables 

in advance. the administrator to navigate the data, set properties for the 
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listed files or folders, create or rearrange directories, delete 
or move files, or perform other general administration tasks. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The same reference numbers are used throughout the 
figures to reference like components and features. 

FIG. 1 is a diagrammatic illustration of a client-server 
system showing remote administration of a server file direc- 
tory over a public network, such as the Internet. 

FIG. 2 shows a block diagram of a computer that can be 
used to implement the client and/or the server in the client- 
server system. 

FIG. 3 shows a remote file administration software archi- 
tecture according to an aspect of this invention. 

FIG. 4 shows steps in a method for remotely browsing a 
server-based file system from a client browser according to 
another aspect of this invention. 

FIG. 5 shows a browser dialog user interface presented on 



Protocol/Internet Protocol), HTTP (Hypertext Transfer 
Protocol) and DCOM (Distributed Component Object 
Model). The client browser renders the Web page into 
human-perceptible forms. 
3 The server computer 22 may implement a firewall soft- 
ware program 32 to protect the Web site. The firewall 32 is 
executed on the server computer or a dedicated computer, 
but is shown separately for illustration purposes. The fire- 
wall 32 blocks many types of unwanted inquiries from 
10 arriving at the Web server. The firewall 32 is conventional in 
that it permits passage of messages conforming to standard 
protocols, such as HTTP, that arrive at well-known and 
designated ports, such as port 80. It is noted that other 
firewalls may be implemented in the communication path 
15 between the client and the server, such as a firewall imple- 
mented on the client side of the Internet 26. 

The server 22 may be connected to an internal computer 
network behind the firewall 32. In the FIG. 1 illustration, the 
server 22 is connected to a second server 34 via a private 
a client computer to browse and remotely administer the 20 network 36 (e.g., LAN, WAN). The second server 34 has its 



server-based file system. 

DETAILED DESCRIPTION 

This invention generally pertains to a system architecture 
that enables remote administration of a server-based file 
directory from a remote client browser using a standard 
network protocol, such as HTTP. The system architecture is 
particularly useful for remote administration over the Inter- 
net and through one or more firewalls. Additionally, the 
system architecture enables the administration tasks to be 
performed securely over an otherwise public network. 

For discussion purposes, this invention is described in the 
context of a Web server application tailored for serving 
documents and programs over the World Wide Web. Remote 
administration of the Web server involves configuring and 
organizing Web pages into a hierarchy of file directories. As 
one example, the Internet Information Server (IIS) manu- 
factured and marketed by Microsoft Corporation is a Web 
server that is extremely configurable and can serve thou- 
sands of files. One aspect of this invention concerns the 
ability to browser the directories of the Web server, such as 
IIS, from a client browser. 

General Architecture 

FIG. 1 shows a simple client-server computer network 
system 20 with a host network server 22 connected to serve 
data to a client 24 via a public network 26. In typical 
operation, the client 24 sends a request for data and/or 
services to the server 22 over the public network 26. The 
server 22 processes the request and returns a response over 
the public network 26. If the request is for data, the server 
22 accesses a database 28 to retrieve the requested data 30 
and returns the data 30 as part of the response. 

The client-server system 20 is representative of many 
different environments. One particular environment of inter- 
est is the Internet. The server 22 runs a Web server software 
program that establishes a Web site on the World Wide Web. 
The server 22 has a file system that organizes files, such as 
Web pages and other documents 30, intojlii ei aichicalidirce- 
wtoricsjThe Web server accepts requests transmitted over the 
Internet from a client-based browser program. The server 
processes the requests and returns one or more Web pages to 
the client 24. The Web pages are commonly written in 
HTML (hypertext markup language) and XML (extensible 
markup language) and are transmitted using conventional 
network protocols, such as TCP/IP (Transmission Control 
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own database 38 with files 40 stored therein. The server 34 
has a file system that organizes the files 40 into hierarchical 
directories. 

yAccorthn^toaaTiiaSpelitgo^tll^ 

network system^Ovirnplements a remote file administration 
architecture tha/enables the client 24 to browse and manage 
the server-based file directories remotely over the Internet 
26 and through thc|firewall 32. The architecture has software 
components residing at both the client and server and these 
components empower the client to perform such adminis- 
trative tasks as Drowsing and listing the file directories, 
configuring the directories, moving existing files, creating 
new files, and so on. The administration architecture utilizes 
standard HTTP commands to gain passage through the 
firewall 32. In addition, the architecture can be extended to 
allow the clicnt^^rowse the directories 40 of another 
^sciycr^^via^heiproxyi server 22. 

The architecture and processes implemented by the archi- 
tecture are described below in more detail, following a brief 
discussion of an exemplary computing system used to 
implement the client and/or server computers. 

Exemplary Computing System 

FIG. 2 shows an exemplary computing system for imple- 
menting aspects of the invention. The computing system is 
shown embodied as a general purpose computing device in 
the form of a conventional personal computer 50. The 
computer 50 includes a processing unit 52, a system memory 
54, and a system bus 56 that interconnects various system 
components, including the system memory 54, to the pro- 
cessing unit 52. The system bus 56 may be implemented as 
any one of several bus structures and using any of a variety 
of bus architectures, including a memory bus or memory 
controller, a peripheral bus, and a local bus. 

The system memory 54 includes read only memory 
(ROM) 58 and random access memory (RAM) 60. A basic 
input/output system 62 (BIOS) is stored in ROM 108. 

The computer 50 may also have one or more of the 
following drives: a hard disk drive 64 for reading from and 
writing to a bard disk or hard disk array; a magnetic disk 
drive 66 for reading from or writing to a removable magnetic 
disk 68; and an optical disk drive 70 for reading from or 
writing to a removable optical disk 72 such as a CD ROM 
or other optical media. The hard disk drive 64, magnetic disk 
drive 66, and optical disk drive 70 arc connected to the 
system bus 56 by a hard disk drive interface 74, a magnetic 
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disk drive interface 76, and an optical drive interface 78, 
respectively. The drives and their associated computer- 
readable media provide nonvolatile storage of computer 
readable instructions, data structures, program modules and 
other data for the computer 50. Although a hard disk, a 
removable magnetic disk 68, and a removable optical disk 
62 are described, other types of computer readable media 
can be used to store data. Other such media include magnetic 
cassettes, flash memory cards, digital video disks, Bernoulli 
cartridges, random access memories (RAMs), read only 
memories (ROM), and the like. 

A number of program modules may be stored on the hard 
disk, magnetic disk 68, optical disk 72, ROM 58, or RAM 
60. These programs include an operating system 80, one or 
more application programs 82, other program modules 84, 
and program data 86. The operating system 80 is preferably 
a Windows brand operating system from Microsoft 
Corpora ti on ^su ch -as -Windo ws .98 oriWindQ ws:NT^a It hon g h 
otiier-rypes-ofcoperating-system^ 
Macmto^:aiul:UMX=opemmg^y5tems? 

An operator may enter commands and information into 
the computer 50 through one or more input devices, such as 
a keyboard 88 and a mouse 90. Other input devices (not 
shown) may include a microphone, joystick, game pad, 
satellite dish, scanner, or the like. These and other input 
devices are connected to the processing unil 52 through a 
serial port interface 92 that is coupled to the system bus 56, 
but may alternatively be connected by other interfaces, such 
as a parallel port, game port, or a universal serial bus (USB). 
A monitor 94 or other type of display device is also 
connected to the system bus 56 via an interface, such as a 
video adapter 96. 

The computer 50 operates in a networked environment 
using logical connections to one or more remote computers. 
The computer 50 has a network interface or adapter 98, a 
modem 100, or other means for establishing communica- 
tions over a network, such as the Internet 26 or the private 
LAN 36. It will be appreciated that the network connections 
shown are exemplary and other means of establishing a 
communications link between the computers may be used. 

Remote File Administration Architecture 

FIG. 3 shows a remote file administration architecture 110 
implemented in the client-server system 20 of FIG. 1. The 
architecture 110 includes software components resident at 
the server 22 and software components resident at the client 
24. Tfte^softwaiercoinpoBtmi^ 
«respectrve:opersririg3y^ 



iisio^ftiConibipat ion-of^ rycr^KicrASPjl 



ninsing 



15 



20 



25 
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A£RS ci'i|i l anrt r^inTt'CTHft 'Scr^pI t ^ wi'ltt t *ITin"^ irv ?S r? r 'p^ In OQC 

implementation, the ASP files include: 

1 . jsbrwls: A file to display a list of files or folders in a 
requested path; 

2. jsbrwflt: A file to display the currently selected file 
name, as well as the ok and cancel buttons; 

3. jsbrwcl: A file to implement the close function of the 
dialog; 

4. jsbrwpop: A file that implements the open function of 
the dialog; 

5. jsbrowscr.asp: A file to display the dialog frames 
(layout); 

6. jsbrower.js: A file containing the client-side utility 
functions, such as selecting a file, and sorting the lists; 

7. jsbrwsct.asp: A file that creates the cached list of folders 
and files in a requested path; and 

8. jsbrwhd.asp: A file that displays the currently selected 
path as well as the column headers. 

9. 

The remote file administration architecture is incorpo- 
rated into existing HTTP browsing tools, rather than being 
embodied as a self-contained binary executable. Incorporat- 
ing the functionality into the existing browser allows use of 
high-level Internet authentication schemes to ensure secure 
access to the Web server's files. 

Remote File Browsing 



Prior to gaining access to the server file system, the client 
first establishes a secure connection with the server. This 
involves an authentication process in which the client and 
server verify each other's identities and software compo- 
35 nents (if desired) followed by encrypted communication 
over the Internet. When the client first attempts to connect, 
the server offers one or more authentication procedures. For 
Windows NT connections, the server offers three choices: 
basic authentication, NTLM (NT LAN Manager), and cer- 
40 tificates. The client elects one of the three choices depending 
upon which its networking system can support. 

Assuming the client elects the certificates option, the 
client and server exchange certificates. These certificates 
typically contain an identity, a public key, and a digital 
45 signature of a trusted certifying authority. If the certificates 
are verified, the client and server use the other's public keys 
to encrypt and decrypt messages exchanged between them. 
The remote file administration architecture operates 
,. „_ _ . . . , , „ . . . within the context of this secured environment. Accordingly, 



On the server side, the remote file administration archi- 
tecture 1 10 includes a file system 112 and a file system 
object 114 that is invoked to discover the file system 112. 
The server-side components further include the Internet 55 
Information Server 116 and a script 118 implemented using 
active server page (ASP) technology. The script is used to 
parse incoming requests to browse or configure the file 
directories and to create a client-side script that is down- 
loaded back to the client in response to the requests. It is 60 
noted, however, that the server may alternatively implement 
code forms other than scripts (e.g., compiled code) to 
implement the functionality described herein with respect to 
script 118. 

On me«cfa^t-sid^-me~rc ^tc^ fc ;adi ii i[iTS D^tioD;airhi- 65 
'rTmrrl1ft"Tn^rt*^"^r^^ 
122 rjn*onc-u ijph3nTOt3lmiiztnKbrc^ 



the server and returning client scripts and data objects to the 
client are all securely exchanged over the Internet and 
through the firewall. 

FIG. 4 show steps in a method for remotely browsing and 
administering file directories in the server-side file system 
112 from the client browser 120. The steps are described in 
conjunction with the system of FIG. 1 and the software 
architecture of FIG. 3. The steps are performed by various 
software components at the client and server, as designated 
by the corresponding captions in FIG. 4. 

At step 200 in FIG. 4, the client calls the browser dialog 
122 by including the script library and initializing a browser 
object, as follows: 
<SCRIPT SR Co" Browse r/JS Browsers" > 
</SCRIPT> 
<SCRIPT> 
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JSBrowser=new BrowserObj(null,! POP.TFILE, script creates a client-side script, which instantiates a custom 

LARGEFONT); client-side object to cache the returned file data such as the 

</SCRIPT> file oame, last date modified, file size, and so forth. That is, 

At step 202 in FIG. 4, the client opens the browser dialog the server generates the program that enables creation of an 

by instantiating a new instance of the browser object with a 5 object on the client side to handle the response to the file 

predefined boolean constant POP, as follows: directory query. Absent this step, the client-side browser 

<INPUT TYPE-TEXT NAME-"pathcnuT'> docs not know what files, folders, or directories it will cache. 

<INPUT TYPE-BUTTON OnClick-"JSBrowser-new ^ Mrver ^us prepares a client-side script that will be able 

BrowserObj(pathcntrL POP.TFILE, LARGEFONT) "> t0 thc information for the client and downloads that 

The variable "pathcnhT* refers to a text field within an 10 script to the client for execution. An example of a server-side 

HTML form that will be populated by the results of the ^P 1 creating a client-side HTML output for execution on 

browser. "POP' is a constant to indicate whether the dialog ^ , client * S^en below under the heading "Client-side 

should be launched. "TFILE" is a constant to indicate if thc Scri P l Generation", 

user is selecting a file or a directory. "LARGEFONT" is a A^e^» t 228, F ftcrf«arcjk6crKlsiM 

constant that affects the dialog size. « nmathricHerrtT Sidci 5c iu j Ucicirtcd»^«uWcryc r. The client 

At step 204, the client launches the browser 120. For the 1 fe loaded Md executed by t he client to renumeratejthe, 

initial launch, the browser dialog 122 displays the last cadieiwttffiibOTes^ 

directory path viewed at the client computer (step 206 in browser dialog can then dispjayaUKM^^^fiieSipbtained, 

FIG. 4). The last path is retrieved from a cookie stored the «fi^tteiseTver^iKh<^ched 1 tocaHyif&iep 206). fiecausejthe 

last time thc administrator launched the browser. datansrcacfredimrthacte^ 

FIG. 5 shows the browser dialog 122 as it is rendered on 20 ^^^^^ rticwit»rcti umrtg« anotti cr«rororni« trip «to « tbc 

the client computer monitor. The browser dialog 122 ^llyli-W 

resembles the familiar file management UI supported by It is noted that the browsing process can be extended to 

Windows-brand operating systems. It includes a "Look in:" enable remote file browsing of physical directories on 

text box 250, a file list 252, and a "File name:" text box 254. another computer connected to the server 22. That is, the 

When first opened, thc dialog 122 displays the last directory 25 server 22 operates as a proxy server to facilitate browsing of 

path, which in this case is "C:", in the "Look inA" text box other computers behind the firewall and connected via a 

250. Within the dialog 122, the administrator may navigate local network. In this implementation, the file system object 

up or down the directory structure by either entering a path is invoked to enumerate the files or directories for the 

into the "Look in:" text box 250 or selecting an item in the requested path that resides 00 a separate computer, such as 

file list 252. Thesdiaiogil22!canmla&d^ 30 server 34. The two local computers could use a conventional 

UMfchasia'hterarcliic^diiector^ architecture, such as SMB shares or NFS shares, to support 

ito^lheilisttafjfliesj remote object transactions. 

With reference again to FIG. 4, if the user selects an item The architecture and process enable a remote administra- 
in the list 252 (i.e., the "yes" branch from step 208),«th$* tor to browse the physical directories on the server site. In 

bnjwscn^QidelernHnosawtretrreMlirei 35 one implementation, the architecture enables an administra- 

tocallftQDithei client- Cstep 210). Ifethey£aitjithejbTO!W^er*120 tor to browse and view both physical and virtual directories 

<refreshesiihesp3ge (step 212). The new page indicates that in a single integrated namespace that reflects the hierarchical 

the item is selected in some manner, such as changing the arrangement of the site as perceived by the client. The 

color of the selected item or displaying a gray background, remote administration tool includes a dynamic namespace 

and shows the path of the selected item in the "File name:" 40 integration mechanism that looks up information maintained 

text box 254 at the bottom of the dialog. If the selected item in a registry (e.g., metabase) for the physical and virtual 

is a folder, its contents will be enumerated and displayed in directories and maps the virtual directories to their appro- 

the list 252 and the "Look in:" text box 250 will be updated priate actual locations as necessary. The administrator then 

with the new path. has a view of the site that corresponds to the view of the 

When the administrator finally selects an item or enters a 45 client browsing the site, i.e., in a hierarchy of the physical 

path that is not cached locally (e.g., a folder), the browser directories and the virtual directories mirroring the hierarchy 

passes a text string of the path back to the instantiating of the URLs. The administrator may then manage the files 

form's path text box, as specified in the initial browser call. under the directories in the namespace via the same entity, 

The path is then passed as a query string via an HTTP such as by setting property values via a user interface of a 

request to the server (step 214 in FIG. 4). Because the path 50 management tool. Moreover, the hierarchical relationships 

is carried in an HTTP request, it passes through the firewall between the physical and virtual directories enable the 

32 to the server 22. properties to inherit properties set on their parent nodes, 

The parsing script 118, which runs at the server in the simplifying management tasks. These properties can span 

context of authenticated users, receives and parses the from virtual directories to physical directories or physical 

request (step 216). Recognizing the path query as pertaining 55 directories to virtual directories. 

to the file system, the script 110 invokes the file system The namespace integration mechanism is described in 

object 114 and derives a new object based upon the posted detail in a co-pending U.S. patent application Ser. No. 

path (step 218). The file system determines whether the path 09/105,398, entitled "Integration of Physical and Virtual 

is a real path within the physical directories (step 220). If the Namespace", which was filed Jun. 26, 1998 in the names of 

path is not contained in the physical directories (i.e., the eo Ronald Meijer, Douglas C. Hebenthal, Lara N. Dillingham, 

"no" branch from step 220), the server returns an error Kim A. Stebbens, James D. Jacoby, and Anthony C. 

message in an HTTP response to the client (step 222). On the Romano. The application is assigned to Microsoft Corpo- 

other hand, if the path exists (i.e., the "yes" branch from step ration and is hereby incorporated by reference. 

220), the file system object 114 enumerates the files or the The above description focuses on remote file management 

directories in the path (step 224). 65 using an HTML browser. It is noted mat aspects of this 

At step 226, the server side ASP script 118 creates a invention may be extended to enable remote management of 

formatted dialog to return to thc client browser. The ASP other local system resources, such as IP addresses, printers, 
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and so forth. Messages in the form of HTTP requests can be 
sent across and bandied by server-side scripts. The scripts 
pass the messages onto the appropriate system resource. 
Then, when constructing a response, the server-side script 
generates a client-side script to be downloaded to the client 
to instantiate an object containing the requested data con- 
cerning the local system resource. 

Example of Server-Side Generation of Client-Side 
Script 

One of the aspects of the remote browsing process is that 
a server-side script creates on behalf of the client a client- 
side script that instantiates a custom client -side object to 
cache the returned file data. As one example, a server-side 
ASP file "jsbrwset.asp" is executed to create a set of files 
and/or folders from the server files system that can be cached 
at the client. The server-side ASP file is written in VBScript 
and, when executed, outputs a script written in JavaScript 
that can be executed on the client to create an object holding 
the file data returned in response to the browser query. The 
code for the ASP file is given below: 



<%@ LANG UAG E- VBScript %> 

<% Option Explicit %> 

<% Response. Expires - 0 %> 

<% 

Const L_PATI TNOTFO UND_TEXT - The path was not found" 
Const L_SLASH_TEXT - "\" 
Const TDIR - 0 
Const TRUE - 1 
Const FTXEDDISK - 2 

Dim i, newid,path, f, sc, fc, ft, FucSy5tem,b type .drive, drives 
Dim primarydrive 

bType - ant(Request.Querystring(1)type")) 
Set FfleSystem-OeateObjectC'ScripUEg.FileSysumObject") 
Set drives » FileSystem.Drives 
For Each drive in drives 
primary drive - drive 

'exit after the first FTXEDDISK if there is one . . . 
if drivcDrivcTypc - FTXEDDISK then 

Exit For 
end if 

Next 

primary drive - piimary drive & L_SLASH_TEXT 
newid ■ 0 

If RequesLQueryString("path**) <>' " Then 
path - RcquesLQueryString("p*th'^ 
if fileSystem.FolderExist»(path) then 

Response.Cookies("irimA , ^("IJVSTPATH , >path 
end if 

Else 

path - Reque«LCookies("HTMlJnrLASTT'ATH*} 
End If 

If path - * "Then 

Response.Cookies ("HTM LA")("LASTPATH* primary drive 

path - primarydrive 
End If 

%> 

<HTML> 
<HEAD> 

<SCRIPT LANOUAGE--JavaScript"> 

<% if FUeSystem.FolderExiBtsCpatli) then %> 
tcp-tnambeadcachcdLisl - sew Array ( ); 
c&chedLtst - top .mi in. he* d. cached Liit; 

<% 

Set f-FHeSystem.GtlFo]der(path) 
Set sc - tSubFolders 
For Bach i In sc 

if L Attributes AND 2 then 

else 

%> 

cschedlistj <%~ newid new 

top.main.hc«Ui3tObi{"<%- Rcplacc(i,-\","\\") 
%>","<%m Lnarne %>"," ",' ","<%m i Type 
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f6>","c%- LDateLastModified %>",irue); 

<% 

newid - newid +■ 1 
end if 

Next 

if bType - TFILE then 
Set fc - f .Files 
For Each in fc 

if fLAttributes AND 2 then 

else 

%> 

cachf ifl istj < c km newid new 

tap.main.headJistObj{''<%- Replace(i,T,"\\") 

ft name %>"," ","<%- fl^ize 
%>""<%m fl.Type *&>","<%- 
fl.DateLastModified %>",&lse); 
<% 

newid - newid + 1 
end if 

Next 
end if 



wp.maiii Jiead.listFuric.se II ndex-0; 
top.mainJisUocation.hrcf •"JSBrwLa.asp"; 
<% else %> 

a!ert(top.mfliniiead document userfonn.cunentP at h.vah^*VV 

L^ATHNOTFOUND_TEXT %>"); 
top.tMin.hcadJocumcnLuserfbrm.currentPaUi.value - "<%- 

Rcpk«(Rcqucst.CookiM("in^l^ ,, )(-Iv\STPATH''),"\","\V') %>"; 
<% end if %> 
</SCRIPT> 
c/HEAD* 
«BODY> 
</BODY> 
</IHTML> 



Notice that the end of the code contains instructions to 
create an HTML form written in JavaScript. Execution of the 
ASP file thereby creates an HTML form having a cached list 
of files/folders returned by the file system object. The HTML 
form output as a result of executing the ASP file is as 
follows: 



40 



top.msin.head.cachcdList - new Array( ); cachedlist - 
top.main.head.cacbedLi»t; 

cachcdList(0}- new 
top.main.head.listOb]("C:\\WINNT","WINN^^'' "," "."File Folder", 
-7/24/97 2:39:00 PM",true); 

cachedListf 1}- new 
top.rMb.hcad.listOb]■( u C:\VI^etpub , ',''Inetpub' , ,'' ""File Folder", 
-7/31/97 8:45 28 PM",true); 

cachedList(2]- new top.main.head.listObj("C:\\PrDgram Files", 
-Program FQes"," "."File Folder","o710/97 2:51:26 PM",trae); 

cachedListf 3}- new top»irmn.head.listObj(X;:\Vteinp*',"lernp" '*,** ", 
-File Folder" "11/12/97 11:19:54 PM>uej; 

cachedList[4}- new 
top.mAb.headJistObjCC:\\ENROLL","ENROLL"," V VFUe Folder", 
-673/98 2:5734 PM",tnie); 
cached Lis t|5}» new 
55 top . main, head J istObj {"C:\\EFORM" "EFORM"," - - " "File Folder", 
-11/4/97 2:48:06 PM",true); 

cached IiitJ 6)- new tor^main.head.listObj("C:\\bin" J -bin'*," " " ", 
-File Folder" "10/14/97 3 39:00 PM\true); 

cachedlist(7jV new 
top.main.headJistObj(-C:\\Beaefits" "Benefits"," **," " "File Folder", 
"12/19/97 3:46:06 PM",trtte): 

cachedLtst(8]- new torilnain.head.listObjf^C:\\MLO"^MLO■',- "," '*, 
"Fde Folder"," 1/12/98 3:1 9 3D PM",irue); 

cached Lis t| 9}- new torj.main.head.listObj(X:V\Multimedia 
Faea","Multimedia Files"," " " "."File Folder", 
-7/2S/97 5:54:30 PM",true); 

top.msin.hesd.lLstFuncsellndei-O; top.rxiain.lisLlocation.href 
""JSBrwLs^sp"; 



60 
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Although the invention has been described in language 
specific to structural features and/or methodological steps, it 
is to be understood that the invention defined in the 
appended claims is not necessarily limited to the specific 
features or steps described. Rather, the specific features and 
steps are disclosed as exemplary forms of implementing the 
claimed invention. 

What is claimed is: 

1. In a client-server computer system, a method for 
browsing server-based physical file directories remotely 
from a client over a network, comprising the following 
steps: 

submitting a directory path in a request from the client to 

the server, the directory path specifying a path in the 

physical file directories; 
generating directory data pertaining to files and/or folders 

enumerated for the directory path; 
creating client-side executable code for execution on the 

client to cache the directory data at the client; and 
returning the executable code and the directory data from 

the server to the client. 

2. A method as recited in claim 1, further comprising the 
step of executing the executable code at the client to cache 
the directory data at the client 

3. A method as recited in claim 2, further comprising the 
step of displaying the directory data at the client. 

4. A method as recited in claim 2, further comprising the 
step of listing the files and/or folders in a graphical user 
interface at the client. 

5. A method as recited in claim 2, further comprising the 
step of displaying a representation of the file directories in 
a graphical user interface at the client. 

6. A method as recited in claim 1, further comprising the 
step of executing the executable code at the client to build 
a graphical user interface and to present the directory data 
within the graphical user interface at the client. 

7. A method as recited in claim 6, further comprising the 
step of navigating the directory data within the graphical 
user interface. 

8. A method as recited in claim 1, wherein the submitting 
step comprises the step of sending the directory path as a text 
string in an HTTP request. 

9. Computer-readable mediate distributed at the client and 
the server to store computer-executable instructions for 
performing the steps as recited in claim 1. 

10. In a client-server computer system in which a client 
submits a request to browse a server-based file directory, a 
method for handling the client request at the server, com- 
prising the following steps: 

extracting a directory path from the request; 
enumerating any files and/or folders for the directory 
path; 

creating executable code for execution on the client to 
cache directory data pertaining to the enumerated files 55 
and/or folders at the client; and 

returning the executable code and the directory data to the 
client. 

11. A method as recited in claim 10, further comprising 
the step of determining whether the directory path exists. 

12. A remote file administration architecture embodied on 
computer-readable media for execution in a client-server 
system, the architecture comprising: 

client -side code resident at a client to enable a user to 
designate a path of a physical file directory located at 
a server and to send a client request that includes the 
path to the server; and 



server-side code resident at the server to receive the client 
request and to generate directory data pertaining to files 
and/or folders for the directory path, the server-side 
code generating client-side executable code for ex ecu - 
5 tion on the client to cache the directory data at the client 
and returning the executable code and the directory 
data to the client. 

13. A remote file administration architecture as recited in 
claim 12, wherein the client-side code comprises a Web 

10 browser and a graphical user interface to present and enable 
navigation of the directory data. 

14. A remote file administration architecture as recited in 
claim 12, wherein the server-side code comprises a Web 
server, a file system interface, and a script to generate the 

15 client-side executable code. 

15. A remote file administration architecture as recited in 
claim 12, wherein the request conforms to HTTP. 

16. A remote file administration architecture embodied on 
computer-readable media for execution in a client-server 

20 system having a client computer connected to a server 
computer via a public network, the server having a file 
system with files and/or folders arranged in physical 
directories, the architecture comprising: 
a client browser resident at a client; 
a client user interface to enable a user to designate a path 

of a physical file directory located at the server; 
the client browser being configured to send a client 

request that includes the path to the server, and 
a server program resident at the server to receive the client 
request and to direct the file system to enumerate the 
files and/or folders for the directory path contained in 
the request, the server program generating executable 
code that can be executed on the client to cache 
directory data enumerated by the file system at the 
client. 

17. A remote file administration architecture as recited in 
claim 16, wherein the request conforms to HTTP. 

18. A remote file administration architecture as recited in 
claim 16, wherein the server program returns the executable 
code and the directory data to the client. 

19. A server software system embodied on a computer- 
readable medium and implemented in a server connected to 
serve one or more clients, the server having a file system 
with files and/or folders arranged in physical directories, the 
server software system comprising: 

code means for receiving a client request to browse the 
file system, the client request specifying a directory 
path of a physical directory; 
code means for enumerating any files and/or folders for 

the directory path; 
code means for creating client-side executable code for 
execution on the client to cache directory data pertain- 
ing to the enumerated files and/or folders at the client; 
and 

code means for returning the executable code and the 
directory data to the client, 

20. A server software system as recited in claim 19, 
further comprising code means for determining whether the 

go directory pass exists. 

21. A server operating system comprising the server 
software system as recited in claim 19. 

22. A network system comprising: 
a client computer having a processing unit, a memory, and 

a browser stored in the memory and executable on the 
processing unit; 
a server computer having a processing unit and memory; 
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a file system implemented on the server computer and 
having files and/or folders organized in directories and 
stored within the server memory; 

a server program stored in the server memory and execut- 
able on the processing unit to receive requests from the 5 
browser on the client computer and to return responses 
to the browser; 

the browser being configured to send a request to the 
server computer, the request specifying a directory path 
within the physical directories of the file system; and 
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the server program being configured to obtain directory 
data for the directory path from the file system and to 
create client-side executable code for execution on the 
client computer to cache the directory data Locally at 
the client, the server program returning the executable 
code and the directory data to the client. 
23. A network system as recited in claim 22, wherein the 
client browser communicates with the server program using 
HTTP messages. 

***** 
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